INFO-ATARI16 Digest Fri, 20 Oct 89 Volume 89 : Issue 539 Today's Topics: Turbo-C Calendar Layout Around the World Hey Borland, why no Turbo C for US? Link format Malloc - what it really does (was: Re: SPUFILE 2.0, C questions) PROGRAM COSTS REFILLING HP DeskJet Cartridges cont... ST in USSR TOS 1.4, memory chips, T16...and the Mega2 STs Turbo C ---------------------------------------------------------------------- Date: Fri, 20 Oct 89 13:09:43 MEZ From: ONM07%DMSWWU1A.BITNET@CUNYVM.CUNY.EDU (Julian Reschke) Subject: Turbo-C Just to clarify the situation: the menus of TURBO-C ARE english! Only documentation and online-help are in German. Perhaps some publishing company should offer an english documentation for Turbo-C? Julian Reschke ------------------------------ Date: 20 Oct 89 06:17:31 GMT From: mcsun!sunic!tut!tukki!suhonen@uunet.uu.net (Timo Suhonen) Subject: Calendar Layout Around the World In article <9953@cadnetix.COM> terrell@cadnetix.COM () writes: >I have another question, about calendars: which day should be in the >leftmost column? Is Sunday always in the leftmost column everywhere? Is >Sunday always in the leftmost column in the USA? If the answer is no - >which other day(s) should be in the leftmost column: Monday? Just >Monday? Al least in Finland Monday is the leftmost column. Timo -- Timo Suhonen suhonen@tukki.jyu.fi Disclaimer: The text above is from my left brain cell. The right one is for SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others... ------------------------------ Date: 20 Oct 89 06:14:38 GMT From: mcsun!sunic!tut!tukki!suhonen@uunet.uu.net (Timo Suhonen) Subject: Hey Borland, why no Turbo C for US? In article limonce@pilot.njin.net (Tom Limoncelli) writes: >is second rate... or at least it doesn't meet "American standards". What are these American standards?? Timo -- Timo Suhonen suhonen@tukki.jyu.fi Disclaimer: The text above is from my left brain cell. The right one is for SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others... ------------------------------ Date: 19 Oct 89 07:02:40 GMT From: mcsun!unido!tub!tmpmbx!netmbx!hase@uunet.uu.net (Hartmut Semken) Subject: Link format In article <2058@pkmab.se> daniel@pkmab.se (Daniel Deimert) writes: >And I think that MWC can produce DRI format files, but I'm not sure. No. It can convert them to MWC format. A one way ticket. >Maybe Alcyon C? Yes. The DRI C compiler does produce DRI object files, indeed. hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Dennis had stepped up into the top seat whet its founder had died of a lethal overdose of brick wall, taken while under the influence of a Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...) ------------------------------ Date: 20 Oct 89 08:21:34 GMT From: mcsun!unido!laura!trillian.irb!klute@uunet.uu.net (Rainer Klute) Subject: Malloc - what it really does (was: Re: SPUFILE 2.0, C questions) In article <1322@engage.enet.dec.com> wallace@oldtmr.dec.com (Ray Wallace) writes: >In article <111500042@uxa.cso.uiuc.edu>, glk01126@uxa.cso.uiuc.edu writes... >> 1) Does Malloc(-1L) not work properly? >This only returns the size of the largest chunk of free memory. So if you have >holes in your free memory (non-contiguous) then it will return a number >smaller than the total of all free memory. From what I have found out Malloc (-1L) returns the *sum* of the sizes of *all* free memory chunks. So, what you should not do without further checking is as follows: buffer_size = Malloc (-1L); buffer_address = Malloc (buffer_size); This will not work as intended because the second Malloc will result in a pointer to the largest available chunk only, not to all the free memory, because the latter is not neccessarily contingous! So the buffer located at 'buffer_address' does not have a size of 'buffer_size' but of some smaller value. The real buffer size you can estimate by adding another statement to those above: real_buffer_size = buffer_size - Malloc (-1L); Disclaimer: I still use TOS 1.0. Dipl.-Inform. Rainer Klute klute@trillian.irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663 ------------------------------ Date: 20 Oct 89 02:58:09 GMT From: emcard!wa4mei!kd4nc!km4ba!alan@gatech.edu (Alan Barrow) Subject: PROGRAM COSTS In article <1989Oct16.133930.21837@utfyzx.uucp> harrison@utfyzx.UUCP (David Harrison) writes: > >Generalising these numbers, we might conclude that it is people who >think good software should cost less the $100 that are "just plain ..." >-- Actually, I conclude that the problem lies with the way Lotus wrote their software..... They welded the sw to the HW platform, which not only made ports difficult, but helped make "compatibility" into the curse of the PC-DOS world. ( 100 man-years to port is the price you pay for squeezing that extra bit of performance out of IBM's sluggard son) Even Lotus's current products show the old school attitude when compared to Excel & others.. ( I canned Lotus at 2.0? ) Excel is virtually device independant compared to lotus. I have no sympathy for applications that insist on reinventing the user interface. It will prob be running on 4 or more O/S ( Including unix ) while lotus is still working on the latest rev. for dos. Not that Excel is the perfect sw package (Just better than most :->), but in most cases, the more rules (O/S, bios, etc) you break, the more trouble you will have porting.... (every programmer knows this, we just do it anyway!) So.... I *do* believe that good sw can be cheap & portable! (and *no*, I do not work for a SW company :-> ) >David Harrison | "God does not play dice with >Dept. of Physics, Univ of Toronto | the universe." -- Einstein >UUCP: uunet!attcan!utgpu!utfyzx!harrison | "Quit telling God what to >BITNET: HARRISON@UTORPHYS | do." -- Niels Bohr Alan Barrow "I am not a computer person...... ..!gatech!kd4nc!km4ba!alan but I play one on TV......" ------------------------------ Date: 20 OCT 89 08:53:20 CST From: Z4648252 Subject: REFILLING HP DeskJet Cartridges cont... It was mentioned that a cartridge was brought back to life which was totally exhausted, i.e., no ink at all, totally dry. The author mentioned that he was under the impression that such cartridges were previously mentioned to be poor candidates for "recharging" due to air pockets on the sponge, etc. His efforts, the removal of the top, I believe and the washing out of the sponge resulted in his cartridge coming back to life. Ok.... the reason that I mentioned, several months back, that exhausted cartridges were poor candidates was that they tend to be 'confused' on their siphon effect. Certain areas on the sponge will be dry while other areas will be wet. This condition will remain even when two ounces of ink have been added. Due to the concentration of ink in certain areas, a "track" will form providing a quick access way to the nozzles. The user ends up getting a dripping effect. Really working with a dry cartridge by removing the top and washing out the sponge will get rid of the dry areas, thus killing the siphon effect. The cartridge will be restored. As always, such restoration attempts involve some risk. The cartridge is not "meant" to be restored and the nozzles have a certain life cycle. Also, ink from a brand relatively unknown should never be used. Hewlett Packard does not endorse (major understatement) the refills, i.e., poor quality ink will result in crusting, thus clogging up the priming tube. Restoration of these expensive cartridges will extend their life considerably. I've been on the same cartridge for several months. Larry Rymal: |East Texas Atari 68NNNers| ------------------------------ Date: 20 Oct 89 06:30:35 GMT From: mcsun!sunic!tut!tukki!suhonen@uunet.uu.net (Timo Suhonen) Subject: ST in USSR In article <595@nadia.UUCP> peterii@nadia.UUCP (Peter Bechtold) writes: >In article <758@utacs.UTA.FI> jackin@utacs.UTA.FI (Markku M?enp??) writes: > > >I can't imagine that the USSR would by ANY computers for their schools within >the next 5 or 10 years. They DO have IBM-compatibles in (technical)schools. At the time I bought my 520ST (In the early 1986), you weren't allowed to sell a ST to USSR. I think it was because of the Motorola prosessor. At that time it was too much 'high- tech'... Timo -- Timo Suhonen suhonen@tukki.jyu.fi Disclaimer: The text above is from my left brain cell. The right one is for SeX and Drugs and Rock'n Roll. Al K. Hall has eaten the others... ------------------------------ Date: 19 Oct 89 06:52:50 GMT From: mcsun!unido!tub!tmpmbx!netmbx!hase@uunet.uu.net (Hartmut Semken) Subject: TOS 1.4, memory chips, T16...and the Mega2 STs In article <891014.11320557.073300@SFA.CP6> Z4648252@SFAUSTIN.BITNET (Z4648252) writes: >1. What memory chips should be used for upgrading the ST2 to a ST4 > if used with the T16? 1-Megabit chips (51 1000, 41 1000) with 120 or 150 nanosecond access time; do not worry about "page mode" or "nibble mode" types: these are special, faster read/write modes for the RAMs, that are not used by the ST MCU. Any type should support the "standard" read/write cycle. The ST timing is made for 150 ns RAMs. Faster RAMs may cause problems: the faster the RAM chip can produce/take data (read/write cycle), the faster it must go from "power down" state (about 30 to 40 Milliwatts) to "power up" state (around 300 Milliwatts). This means, the suppy current has to jump from <8 mA to ?60 mA; this leads to voltage drops on the power lines (the faster the jump, the less power left for the RAM...) The 1985 Rev. C 520 ST+ did not cause a lot of trouble when the capacitators for each RAM were replaced with 200 nanofarads. If You want to "recycle" the RAM chips for a new machine (there *will* be another computer in Your life!), get fast chips (70 nanosecond) and a bag of 200 nF capacitators; solder the capacitators between Vcc and Vss under the RAM socket (on solder side of the PCB); if it does not work, solder a second capacitator to every RAM chip; this gives 400 nF per chip and should be all You need. >2. Should the chipped TOS 1.4 be transferred to fast EPROMS to gain > maximum results from the T16? Well, the fastest bus cycle of the 8 MHz 68000 MPU is about 250 nanoseconds long (do not have the specs at hand, maybe its a little less), so the acces of 250 ns ROM/EPROM does not require "wait states" (think about a loop, that fills all registers from memory; with "no wait" the MPU speed is the limiting factor, not the memory speed). However, the 16 MHz MPU is twice as fast; if the memory can produce/take data at the doubled speed, You'll get no wait states, too. Of course a faster ROM is necassary to handle this speed. 200 ns ROMs/EPROMs will do it with a little trick: the acces time of EPROMS is measured from the activation of -CE (Chip Enable, low active): 250 ns after -CE the data outputs will be valid. You can think of -CE controling a large transistor that switches the power to the chip on and off; disabled, the chip is sleeping (and taking less power, producing less heat), -CE awakes it. Now, there is another control input, called -OE (Output Enable). This one enables the output drivers of the (awake) chip. If the chip is held awake (-CE constant low), the acces time (after activation of -OE) is a lot (!) faster than nominal speed. Its less than half the nominal acces time. The chip is now twice as fast: it can catch up with a MPU, that is twice as fast. The faster adress decoding and timing is - of course - not handeled by the ST chip set. The accelerator board has to provide the new control lines. >3. Should the Atari blitter be replaced with the newer? Hmm. Terra incognita, data input required. :-) hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Dennis had stepped up into the top seat whet its founder had died of a lethal overdose of brick wall, taken while under the influence of a Ferrari and a bottle of tequila. (Douglas Adams; the long dark teatime...) ------------------------------ Date: 20 Oct 89 11:07:42 GMT From: mcsun!hp4nl!dutrun!robert@uunet.uu.net (Robert de Vries) Subject: Turbo C In article <1989Oct19.100825.21264@stag.UUCP> ardvar!krs@stag.UUCP (Kent Schumacher) writes: [... stuff deleted ...] >Does it have a built in editor, or are you allowed >to substitute your own (without an unacceptable loss of features). It is has a built-in editor, but I don't know if you can substitute your own. I don't think so at least. >Is it a CLI environment (like MWC) or a GUI. Both. >If it has a build in editor, is it gem based, does it allow marking blocks >with the mouse (like Laser C), does it allow multiple windows, macros, ...? It is GEM-based, you can mark blocks with your mouse, multiple windows, no macros. >(Oh, yeah - any comment on the documentation and 'ANSI-ness' of the compiler >would be appreciated). Full fledged ANSI. I love it. Robert. ------------------------------ End of INFO-ATARI16 Digest V89 Issue #539 ***************************************** =========================================================================